package com.zjl.redis.第03章_redis持久化;

/**
 * ●AOF和RDB同时开启，系统默认取AOF的数据
 * 如遇到AOF文件损坏，可通过
 * redis-check-aof --fix appendonly.aof
 * 进行恢复  其实  没啥用
 *
 * ➢何时重写
 * 重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，
 * 因此设定Redis要满足一定条件才会进行重写。
 * ➢AOF同步频率设置  每次都会同步到缓冲区，再进行接下来的同步
 * ●始终同步，每次Redis的写入都会立刻记入日志 # appendfsync always
 * ●每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。 appendfsync everysec
 * ●把不主动进行同步，把同步时机交给操作系统。# appendfsync no
 *
 * Rewrite
 * AOF采用文件追加方式，文件会越来越大为避免出现此种情况,
 * 新增了重写机制，当AOF文件的大小超过所设定的阈值时,
 * Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的
 * 最小指令集.可以使用命令 bgrewriteaof  手动 aof 既是配置是关掉的，也能保存
 * 如set 1 1   set 1 2   set 1 3 //之前的都覆盖了  只保存set 1 3指令
 *  //根据redis保存的内容   智能识别出指令保存
 *
 * AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),
 * 遍历新进程的内存中数据，每条记录有一条的Set语句。
 * 重写aof文件的操作,并没有读取旧的aof文件，而是将整个内存中的数据库内容用
 * 命令的方式重写了一个新的aof文件，这点和快照有点类似。
 * //根据redis保存的内容   智能识别出指令保存
 *
 *
 * auto-aof-rewrite-percentage 100
 * auto-aof-rewrite-min-size 64mb
 * ●系统载入时或者.上次重写完毕时，Redis会记录此时AOF大小,
 * 为base_size,如果Redis的AOF
 * 当前大小 >= base_size+base_size*100% (默认)
 * 且当前大小 >= 64mb(默认)的情况下，
 * Redis会对AOF进行重写。
 *
 *
 *
 * no-appendfsync-on-rewrite no
 * # aof重写期间，是否同步
 *  同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，
 *  而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形
 *  如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题
 *  如果设置为yes，这就相当于将appendfsync设置为no，
 *    这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞
 *  在linux的操作系统的默认设置下，最多会丢失30s的数据。
 *
 *
 */
public class AOF的重写机制 {

}
